Graphical user interfaces typically employ some form of a window manager to organize and render windows. Window managers commonly utilize a window tree to organize windows, their child windows, and other objects to be displayed within the window such as buttons, menus, etc. To display the windows on a display screen, a window manager parses the window tree and renders the windows and other user interface objects in memory. The memory is then displayed on a video screen. A window manager may also be responsible for “hit-testing” input to identify the window in which window input was made. For instance, when a user moves a mouse cursor over a window and “clicks,” the window manager must determine the window in which the click was made and generate a message to that window.
In some operating systems, such as Windows®NT from the Microsoft®Corporation of Redmond, Wash., there is a single window manager that threads in all executing processes call into. Because window manager objects are highly interconnected, data synchronization is achieved by taking a system-wide “lock”. Once inside this lock, a thread can quickly modify objects, traverse the window tree, or any other operations without requiring additional locks. As a consequence, this allows only a single thread into the messaging subsystem at a time. This architecture provides several advantages in that many operations require access to many components and also provides a greatly simplified programming model that eliminates most deadlock situations that would arise when using multiple window manager objects.
Unfortunately, a system-wide lock seriously hampers the communications infrastructure between user interface components on different threads by allowing only a single message to be en-queued or de-queued at a time. Furthermore, such an architecture imposes a heavy performance penalty on component groups that are independent of each other and could otherwise run in parallel on independent threads.
One solution to these problems is to change from a system-wide (or process-wide) lock to individual object locks that permits only objects affected by a single operation to be synchronized. This solution actually carries a heavier performance penalty, however, because of the number of locks introduced, especially in a world with control composition. Such a solution also greatly complicates the programming model.
Another solution involves placing a lock on each user interface hierarchy, potentially stored in the root node of the window tree. This gives better granularity than a single, process-wide lock, but imposes many restrictions when performing cross tree operations between inter-related trees. This also does not solve the synchronization problem for non-window user interface components that do not exist in a tree.
Therefore, in light of the above, there is a need for a method and apparatus for providing high-performance message queues in a user interface environment that does not utilize a system-wide lock but that minimizes the number of locked queues. There is a further need for a method and apparatus for providing high-performance message queues in a user interface environment that can integrate a high-performance non-locking queue with a queue provided by a legacy window manager.